Post

Replies

Boosts

Views

Activity

Recovering gracefully from AUv3 crash
I am in the process of porting my AU host from the AUv2 to the AUv3 API and, since AUv3 Audio Units run in a separate process, I was hoping to be able to recover gracefully from plug-in crashes. If memory serves well, this was even one of the advantages of AUv3 touted by Apple when they were first introduced a few years back. Unfortunately, a few days of experimentation have left me rather frustrated. What seems to happen is that if an AUv3 effect crashes in the middle of processing audio, then its renderBlock gets stuck forever on a semaphore waiting for a signal that never comes. This would be bad enough by itself, but has the rather nasty side effect of causing a deadlock as soon as the host sends pretty much any message to the AUAudioUnit instance, including trying to release it or to invalidate its resources. Note that Apple's own AUv3Host sample code freezes when faced with a crashing AUv3 Audio Unit. My current workaround is to detect the crash by listening to kAudioComponentInstanceInvalidationNotification and then leak the AUAudioUnit object on purpose and ask the user to relaunch the application. This seems to work but is clearly a horrible hack. So my question is whether anyone with experience hosting AUv3 effects knows how to gracefully recover from a crash of the effect without creating unwelcome side effects like blocked threads / leaked objects / etc?  Thanks a lot! Best, Martin
2
0
653
Jun ’20
AudioServer plugin as System Extension?
Hi, my app requires an AudioServer driver for full functionality. Everything works fine if I install the driver "by hand" in Library/Audio/Plug-Ins/HAL, but my understanding is that I cannot do this for an App distributed through the App Store. It seems that System Extensions are the way to go, but I'm having problems implementing this. I've made sure that the driver has a bundle ID of the form app.bundle.id.drivername and the bundle's name is app.bundle.id.drivername.driver located in my app's Content/Library/SystemExtensions folder. The app also has the corresponding entitlement. However, when I submit an activation request for the driver, I always get the error message "OSSystemExtensionErrorDomain Code 4: Extension not found in App bundle". Any idea what causes this and if bundling an AudioServer plugin as a System Extension is even possible? For what it's worth, I've turned off SIP and typed systemextensionsctl developer on so testing is supposed to work...
3
0
905
Jul ’20
"The save file operation failed"
Hi, I am maintaining an NSDocument based application that uses the "old" model for the Save, Save As, etc functions. In the latest version of Ventura, choosing File -> Save As results in an alert with the message "The save file operation failed" as well as the following printout to the console: 2022-11-15 00:21:26.122507+0000 MyApp [miscellany] CLIENT ERROR: remote view delegate NSSavePanel lacks method which can react to the details of Error Domain=com.apple.ViewBridge Code=0 "(null)" UserInfo={com.apple.ViewBridge.error.hint=advance to run phase, com.apple.ViewBridge.error.description=NSViewBridgeErrorUnknown} 2022-11-15 00:21:26.123129+0000 MyApp [OpenSavePanels] Could not advance an Open/Save panel to run phase due to error: Error Domain=com.apple.ViewBridge Code=0 "(null)" UserInfo={com.apple.ViewBridge.error.hint=advance to run phase, com.apple.ViewBridge.error.description=NSViewBridgeErrorUnknown} I have absolutely no idea what this means except that for some reason the "powerbox" fails to work as intended... Any clue? Note that this app has been running fine on macOS 10.8 all the way up to the first beta of macOS 13.1. Only the current second beta throws the alert. How would I even go about debugging this? As far as I can see, the only control I have on the file savings dialog is via the -(BOOL)prepareSavePanel: hook, but even throwing that out completely doesn't change the behaviour. It really looks like this is a bug in the latest beta of Ventura, but since I cannot produce a MWE (the app is too large to be able to just chuck out stuff until there's a MWE left) it's not clear how to even write a bug report.
0
0
894
Nov ’22